ci: split build out of test workflow#2197
ci: split build out of test workflow#2197thompson-tomo wants to merge 40 commits intoopen-telemetry:mainfrom
Conversation
thompson-tomo
requested review from
a team,
ahayworth,
arielvalentin,
dazuma,
ericmustin,
fbogsany,
hannahramadan,
kaylareopelle,
mwear,
plantfansam,
robbkidd,
robertlaurin,
simi and
xuan-cao-swi
as code owners
thompson-tomo
changed the title
thompson-tomo
force-pushed
the
build_splitOut
branch
from
88a5bfa to
790e2cc
Compare
thompson-tomo
force-pushed
the
build_splitOut
branch
from
790e2cc to
213b66c
Compare
Co-authored-by: Ariel Valentin <arielvalentin@users.noreply.github.com>
|
Although I appreciate wanting to split apart steps the cost is an increasing matrix of jobs and complexity to wrap our heads around. I am not sure this change is necessarily a net improvement as it will potentially add hundreds of jobs in the worst case. |
|
While I agree there is scenarios that could result in a significant increase in checks the goal would be to minimise these. The main scenario I can think of is bumping the min runtime which happens once a year or bumping a dependency in the root Gemfile. Where splitting the workflows simplifies things is in the test workflow as we can easily have a matrix of runtimes & os to test against without needing to have a bunch of conditional logic on steps. |
Added new label configuration for 'everything' to include specific files.
|
@arielvalentin i believe I have come up with a nice solution to address your concerns. If the everything label is added, it will only add 1 check which is a recursive build of all gems. The everything label is added if the root Gemfile or Rakefile is changed. This would be the case when yard/rubocop is updated. The three scenarios can be seen in:
So when the gem selection process is replicated to testing workflows most pr's will see a significant reduction in the number of checks for instance #2231 would go from 64 checks down to 16 hence more manageable and efficient. |
I'm a little confused by why that would be the case for #2231. When the base gem changes, it has a direct impact on child gems. That should trigger a cascade that runs tests for all instrumentation. Why would this change result in fewer checks? |
|
Ahh, I didn't notice that base was also being changed. It should still reduce the number of checks to be any gems explicitly changed as a dedicated check and a complete build check. I have made that tweak now. |
3 participants
This introduces a ruby build Workflow which is responsible for building documentation and the gem. Previously this was being done via the testing Workflow only on 1 runtime.
By splitting it out in the future we can remove the build step from the testing workflows which will facilitate further optimisation in particular having all runtime testing behaving the same and more significantly using a matrix property for runtimes.
It is important to note that we have managed to restrict which gems are built to just be those that have changed hence improves ci performance.
This pattern of restricting will be replicated to the test workflows in the future hence brings benefit across the board.
In cases such as merge queue all gems will be built.
An example of what happens if no gems are identified can be seen at thompson-tomo#201